Android Pentest - Abdelaziz Elhawary

Applications is the top layer of android architecture. The pre-installed applications like home, contacts, camera, gallery etc and third party applications downloaded from the play store like chat applications, games etc. will be installed on this layer only.

It runs within the Android run time with the help of the classes and services provided by the application framework.

Application Framework provides several important classes which are used to create an Android application. It provides a generic abstraction for hardware access and also helps in managing the user interface with application resources. Generally, it provides the services with the help of which we can create a particular class and make that class helpful for the Applications creation.

It includes different types of services activity manager, notification manager, view system, package manager etc. which are helpful for the development of our application according to the prerequisite.

Android Runtime environment is one of the most important part of Android. It contains components like core libraries and the Dalvik virtual machine(DVM). Mainly, it provides the base for the application framework and powers our application with the help of the core libraries.

• Like Java Virtual Machine (JVM), Dalvik Virtual Machine (DVM) is a register-based virtual machine and specially designed and optimized for android to ensure that a device can run multiple instances efficiently. It depends on the layer Linux kernel for threading and low-level memory management.

• The core libraries enable us to implement android applications using the standard JAVA or Kotlin programming languages as Kotlin is decombiled and understood by the OS as java too.

Android runtime —> runs every application in a distinct VM

The Platform Libraries (Native) includes various C/C++ core libraries and Java based libraries such as Media, Graphics, Surface Manager, OpenGL etc. to provide a support for android development.

• Media library provides support to play and record an audio and video formats.

• Surface manager responsible for managing access to the display subsystem.

• SGL and OpenGL both cross-language, cross-platform application program interface (API) are used for 2D and 3D computer graphics.

• SQLite provides database support and FreeType provides font support.

• Web-Kit This open source web browser engine provides all the functionality to display web content and to simplify page loading.

• SSL (Secure Sockets Layer) is security technology to establish an encrypted link between a web server and a web browser.

• libc —> library for C-developed apps

Linux Kernel is heart of the android architecture. It manages all the available drivers such as display drivers, camera drivers, Bluetooth drivers, audio drivers, memory drivers, etc. which are required during the runtime.

The Linux Kernel will provide an abstraction layer between the device hardware and the other components of android architecture. It is responsible for management of memory, power, devices etc.

The features of Linux kernel are:

• Security: The Linux kernel handles the security between the application and the system.

• Memory Management: It efficiently handles the memory management thereby providing the freedom to develop our apps.

• Process Management: It manages the process well, allocates resources to processes whenever they need them.

• Network Stack: It effectively handles the network communication.

• Driver Model: It ensures that the application works properly on the device and hardware manufacturers responsible for building their drivers into the Linux build.

• On Android, applications are written in Java but run on the Dalvik virtual machine.

• The Java source code is compiled into a different byte format called the Dalvik executable format, optimized for ARM architecture. This format helps conserve resources and battery life on mobile devices.

• The Dalvik executable format is represented as an optimized text file format called .dex . It contains classes that are generated from the Java source code in the Dalvik executable format. If needed, the .dex file can be converted back to a regular java file format by jadx to be read, but to edit you need to edit smali.

• One important limitation of the .dex file is that it can only contain 65,535 methods. If an application exceeds this limit, it will result in multiple .dex files, named classes.dex, classes2.dex, and so on. Libraries, frameworks, and the Android system itself may also lead to multiple .dex files due to the number of methods they contain.

“ghex” tool is suitable to disassemble the code sections of the “classes.dex” file, revealing the dalvik executable code (smali code)

Smali is an assembly-like programming language used in Android app development and reverse engineering. It is the output of the Dalvik bytecode decompilation process and represents the low-level code that runs on Android’s Dalvik Virtual Machine (DVM), Smali can be considered analogous to assembly language, but for Android applications. Both Smali and assembly are low-level, human-readable representations of code that target specific virtual machines or processor architectures.

• Could be used to bypass any client side validations by editing Smali code

• Tests the tamper validations, as APKs shouldn't be working after editing the Smali code and patching it then recompiling “Building” it back

both java and kotlin are considered java, as kotlin developed code is translated to be understood by the Dalvik into java too

Flutter applications

Also known as (Non-proxy aware applications) , they dont follow proxy routing and the traffic directed to the server and uses special certificate in such connection

to validate if the application is Flutter or not, by jadx-gui check the io folder, should contain flutter, io maybe obfuscated ⇒ p313io

💡

to intercept Flutter based apks ⇒ use reFlutter

https://github.com/ptswarm/reFlutter

Also read this:

Pentesting Flutter mobile apps (Android) - HackMD

# Pentesting Flutter mobile apps (Android) Recently I had an opportunity to perform a penetration t

https://hackmd.io/@runicpl/flutter-android

Xamarin applications

💡

you can make .NET APKs using Xamarin, as well as “IOS and Desktop” application.

If you checked Jadx-gui you wont find the code just some statics

Code is stored in DLLs stored in the application

so we first decompile it using apktool d

we find here the code we want to read

first we need to use this script to de-compress them before reversing

https://github.com/x41sec/tools/blob/master/Mobile/Xamarin/Xamarin_XALZ_decompress.py

then use ⇒ dnSpy.exe to reverse the DLL files and fetch the readable code

its built on the UID separation that aims to organize access ,resources and files of each app.

When an app is installed or uninstalled on the device, the Package Manager updates this file /data/system/packages.xml to reflect the changes in the system’s package database. The file is essential for keeping track of the installed apps and their permissions.

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<packages>
    <package name="com.example.app1" codePath="/data/app/com.example.app1" nativeLibraryPath="/data/app/com.example.app1/lib" flags="..."
        version="12345" userId="10000" installer="com.android.vending">
        <!-- More details about the package -->
        <sigs count="1">
            <cert index="..." />
        </sigs>
        <perms>
            <item name="android.permission.CAMERA" granted="true" flags="0" />
            <item name="android.permission.INTERNET" granted="true" flags="0" />
            <!-- More permissions -->
        </perms>
        <!-- More details about the package -->
    </package>

    <package name="com.example.app2" codePath="/data/app/com.example.app2" nativeLibraryPath="/data/app/com.example.app2/lib" flags="..."
        version="67890" userId="10001" installer="com.android.vending">
        <!-- More details about the package -->
        <sigs count="1">
            <cert index="..." />
        </sigs>
        <perms>
            <item name="android.permission.CAMERA" granted="true" flags="0" />
            <item name="android.permission.RECORD_AUDIO" granted="false" flags="0" />
            <!-- More permissions -->
        </perms>
        <!-- More details about the package -->
    </package>
</packages>

the content is something like is as we see every app has its own userId that can access the data belongs to this app only.

it depends on the permissions located on the android manifest.xml file under <permission> & <uses-permission> tags.

• <permission>

<permission> is used to define custom permissions that you create and control within your app. It does not request access to device features or data directly; instead, it sets up access controls within your app or allows you to share functionality with other apps while maintaining controlled access.

<permission android:description="string resource"
            android:icon="drawable resource"
            android:label="string resource"
            android:name="string"
            android:permissionGroup="string"
            android:protectionLevel=["normal" | "dangerous" |
                                     "signature" | ...] />

• <uses-permission>

<uses-permission> is used to request permissions required by your app to access device features or data. It is a declaration that informs the Android system of your app's permission requirements and is presented to the user during installation for their approval.

Specifies a system permission that the user must grant for the app to operate correctly. The user grants permissions when the application installs, on devices running Android 5.1 and lower, or while the app runs, on devices running Android 6.0 and higher.

<uses-permission
     android:name="android.permission.WRITE_EXTERNAL_STORAGE"
     android:maxSdkVersion="18" />

 <permission
        android:name="com.example.providerapp.PERMISSION_ACCESS_DATA"
        android:label="Access Provider App Data"
        android:protectionLevel="dangerous" />

 <!-- Request permission to access data from the Provider App -->
    <uses-permission android:name="com.example.providerapp.PERMISSION_ACCESS_DATA" />

• Known as "white-box" analysis, involves examining the source code, binary code, or application package (APK) file without executing the app. It looks for vulnerabilities, security issues, and potential weaknesses in the code and resources.

• Static analysis is typically performed during the early stages of app development or before the app is deployed.

• Static analysis is effective at identifying potential security issues within the code, such as hardcoded credentials, insecure data storage, insecure code patterns or any insecure component implementations.

• Static analysis can identify issues that might not be apparent during dynamic analysis, such as hardcoded secrets or hidden vulnerabilities in the code

The AndroidManifest.xml file is a critical configuration file in an Android application. It's located in the root directory of the app's source code and contains essential information about the app's structure, components, permissions, and metadata.

<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1" android:versionName="1.0" package="com.mwr.example.sieve">

The package attribute in the Android manifest file specifies the unique identifier for the Android application. The package name is used to uniquely identify the app on the device and in the Google Play Store which is here “com.mwr.example.sieve”.

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.INTERNET"/>

Review these permissions to ensure they are necessary and not overly permissive.

<permission android:label="Allows reading of the Key in Sieve" android:name="com.mwr.example.sieve.READ_KEYS" android:protectionLevel="dangerous"/>
<permission android:label="Allows editing of the Key in Sieve" android:name="com.mwr.example.sieve.WRITE_KEYS" android:protectionLevel="dangerous"/>

- These lines define custom permissions for the app. These custom permissions are related to reading and writing keys and are marked with a protection level of “dangerous.”

- Evaluate how these custom permissions are used in the app and if they are correctly protected and justified, custom permissions are related to the context of the app.

<uses-sdk android:minSdkVersion="8" android:targetSdkVersion="17"/>

• android:minSdkVersion: This attribute specifies the minimum Android version (API level) that your application can run on.

• android:targetSdkVersion: This attribute specifies the target Android version that your application was designed for.

This doesn't necessarily mean your application won't run on newer versions; rather, it indicates that you've tested and optimized your app for this particular version.

If the targetSDK version is <= 17, and the stars align you could have RCE via CVE-2012–6636.

we have three files are part of the Android operating system and are related to various aspects of the system’s configuration and permissions. Here’s a brief overview of each file

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<packages>
    <package name="com.example.app1" codePath="/data/app/com.example.app1" nativeLibraryPath="/data/app/com.example.app1/lib" flags="..."
        version="12345" userId="10000" installer="com.android.vending">
        <!-- More details about the package -->
        <sigs count="1">
            <cert index="..." />
        </sigs>
        <perms>
            <item name="android.permission.CAMERA" granted="true" flags="0" />
            <item name="android.permission.INTERNET" granted="true" flags="0" />
            <!-- More permissions -->
        </perms>
        <!-- More details about the package -->
    </package>

    <package name="com.example.app2" codePath="/data/app/com.example.app2" nativeLibraryPath="/data/app/com.example.app2/lib" flags="..."
        version="67890" userId="10001" installer="com.android.vending">
        <!-- More details about the package -->
        <sigs count="1">
            <cert index="..." />
        </sigs>
        <perms>
            <item name="android.permission.CAMERA" granted="true" flags="0" />
            <item name="android.permission.RECORD_AUDIO" granted="false" flags="0" />
            <!-- More permissions -->
        </perms>
        <!-- More details about the package -->
    </package>
</packages>

<?xml version="1.0" encoding="utf-8"?>

<permissions>
    <!-- Define permission groups -->
    <permission-group name="android.permission-group.LOCATION" >
        <item name="android.permission.ACCESS_FINE_LOCATION" />
        <item name="android.permission.ACCESS_COARSE_LOCATION" />
    </permission-group>

    <!-- Define permissions -->
    <permission name="android.permission.ACCESS_FINE_LOCATION" >
        <group gid="android.permission-group.LOCATION" />
        <!-- More details about the permission -->
    </permission>

    <!-- More permission groups and permissions -->
</permissions>

⇒ (Activities, Services, Broadcast Receivers, Content Providers) that 50% of vulns,

⇒ and 50% are related to network traffic (e.g., HTTPS).

adb shell dumpsys window | grep 'mCurrentFocus'

adb shell dumpsys window | select-string "mCurrentFocus"
adb shell dumpsys activity activities | Select-String "mResumedActivity"

The main parts to check when we are testing any apk:

1. Software : its the java code and how it interacts with operating system or with other components.

2. Web : Whether the app communicate over network or not, the app requests details and we also intercept these requests [here, the task you make will be a web-pentest more than android]

3. Network : is it http or https, can implement SSL pinning or not.

4. Interacting with system check for sensitive data that stored with unsecured way.

How software can be analyzed?

1. Static Analysis : by looking at the source code without running the application.

2. Dynamic Analysis : it happens in runtime and can be done by for example leaking crypto-keys , seeing encrypted values in memory.

1. After starting Nox

   netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=62001 connectaddress=127.0.0.1 connectport=62001

   adb connect 192.168.1.8:62001

2. After Closing Nox

   netsh interface portproxy delete v4tov4 listenport=62001 listenaddress=0.0.0.0

• Your device should be set in Developer mode, and the USB Debug is enabled or whatever way you will connect

• Ensure that your Windows firewall allows incoming connections on port 62001.

• in the case of Nox ⇒ it starts by default on localhost in port 62001
  • adb connect <HOST_MACHINE>:62001
  • adb shell

• You can execute shell adb commands directly using ⇒ adb shell ….

Port Tunneling

In case the adb port is only accessible from localhost in the android device but you have access via SSH, you can forward the port 5555 and connect via adb:

ssh -i ssh_key username@10.10.10.10 -L 5555:127.0.0.1:5555 -p 2222

adb connect 127.0.0.1:5555

adb shell am start -a [actionName inside intent-filter]  
#ex: adb shell am start -a jakhar.aseem.diva.action.VIEW_CREDS
or
adb shell am start -n [acivityPackageName with /]
#ex: adb shell am start -n jakhar.aseem.diva/.APICredsActivity

WebView

• We want to be able to control the input to the webView

• Check for Exported activity supports Webview in manifest by searching fot webView or loadUrl

• head to onCreate if activity , onStartCommand if service

• Here if we didn’t pass the value of is_reg it will be false by default

• we will pass the activity by extra string value to the reg_url variable, to load our URL

• loadUrl(…..) is a built-in function in java ⇒ loads the url and it also support the file scheme as long as the APK has the Permission READ_EXTERNAL_STORAGE

e.g ⇒ so we can use the URL input to view : file:///etc/hosts

• to export activity with extras, mean that u give additional parameter value in the request
  • --es ⇒ String extra
  • --ei ⇒ Integer extra
  • --ez ⇒ Boolean extra

adb shell am start -n com.tmh.vulnwebview/.RegistrationWebView --es reg_url "www.example.com"

• By this method we can also load Files by the permission of the APP if it has access to some files

---

• Diva example

• in AndroidManifest.xml , the activity that has the above intent-filter, will execute the action

• we can also address the activity itself directly

• strings.xml contains the string values for variables

💡

check_pin ⇒ String value to the chk_pin variable.
Because of this:
getString(R.string.chk_pin)

in i.putExtra(getString(R.string.chk_pin), chk_pin);
and
false is the value of the chk_pin

💡

if the WebView.setWebContentDebuggingEnabled(true) you can access the App from the LAN and control the screen and execute js

• Remote Debugging

  Some times the web view can contain this option

  

  This allow the remote debugging, this option can be used if you are on the same network with the victim and he uses app that has web view with this enabled option, then you can control the web view and see what he sees in the app and execute JavaScript code in the context of this web view. This can be done by opening this URL chrome://inspect/#devicecs from chrome and waits for the victim to open the application that has this web view option.

  

  if you click on inspect in the bottom of the image, you can directly access the web view and also you can then execute js code from the developer tool inside the browser and it will appear on the victim’s screen and also you can execute xhr object to read files from the system and send it to me

---

• setAllowUniversalAccessFromFileURLs() bypasses SOP
  • If you set setAllowUniversalAccessFromFileURLs(true) This setting primarily affects JavaScript's ability to access content from local files within the WebView. While it can be used to relax the Same-Origin Policy for file URLs

• SetJavaScriptEnabled() supports you to execute js in web view context.
  • setAllowUniversalAccessFromFileURLs(true) here allow js execution from your local files using file schema URLs and this removes any restrictions to same origin policy and permit the web view to send web requests from local file in the system. if it’s true we can use it to make JS file that sends sensitive data to a remote attacker server with web requests.

• ex.

https://beeceptor.com/ ⇒ allow you to make Endpoint to forward your request and see its body

---

• Web views in android allows you to use JavaScript and can be enabled through this line.

• This line makes an interface between JavaScript used in web view and java source code used inside the app.

• So, JavaScript can call any public method defined from WebAppInterface() objects or in this class actually.

This interface takes 2 parameters

1- the exposed interface WebAppInterface()

2- the reference that will be called from the JavaScript code. in our example "Android"

This can be used to invoke native utilities from your phone like sending SMS to anyone or stealing your account information. Here is an js example of calling function inside this class :

• Old school attacks

  In the past from android 4, if you can render the java code from web view then you can control the whole app and get to RCE from it. For example :

  

  the purpose of this code is to use java reflection (which allow you to return to the base class) and get instance from Runtime object where you can execute system commands from java. All of this things can be done when you can access the java code.

  This was used to write ARM binary and drop it in the system then execute it, this can steal things from sdcard for example like photos, videos and so on. Also if the app don’t have the storage permission so the attacker can not read from sdcard , he still can use ginger break vulnerability or ds noter from which he can get root on the system.

  NOW , the android apps have protection from all reflection based attacks. by using this option :

  

  This option permits checking to the loaded URL and make validations on it to stop the injection attacks.

• If you find a native functions , that means its code is inside native library not in java code, you will find it in the lib Directory inside the APK after decomposing its components using APKtool

IDA tool to reverse non java code to see the assembly code

Broadcast receivers are components in an Android app that enable the app to respond to system-wide events or custom events. These events, known as broadcasts, can originate from the system itself, other apps, or even the app's own code. Broadcast receivers can be categorized into static and dynamic based on how they are registered.

1. Static Receivers:
   Static receivers refer to
   broadcast receivers that are declared in the AndroidManifest.xml file of the application. They are set up to listen for specific broadcast events, such as device booting, network connectivity changes, or custom events. Static receivers are registered automatically when the application is installed and do not require the app to be running actively.

2. Dynamic Receivers:
   Dynamic receivers, on the other hand,
   are not declared in the AndroidManifest.xml file. Instead, they are registered and unregistered programmatically within the app's code using registerReceiver function. This allows the app to control when the receiver is active and listening for specific broadcast events. Dynamic receivers can enhance security to some extent, as they are not exposed for potential exploitation via static declaration in the manifest.

Insecure broadcast receiver

• function registerReceiver ⇒ starts a Dynamic Receivers

• for static receivers :

1. Check <reciever> in manifest if Exported “Explicitly or Implicitly by intent-filter”

   

   Its Not a must to be exported ⇒ it may be used to respond to broadcast within the app

2. Jump to onRecieve Function in both static and dynamic ⇒ to check for extras needed

⇒ receives 3 strings as extras

3. search by the action name to check any functions call the receiver action to check for example

   

   In our example here’s the Function that required a Receiver , receives 3 strings as extras

now we can use it to push a notification

adb shell am broadcast -a service.vulnerable.vulnerableservice.LOG --es data "TEST" #example from PIVAA
adb shell am broadcast -a infosecadventures.allsafe.action.PROCESS_NOTE --es server "10.10.10.10" --es note "Hello" --es  notification_message 'AndroidPT' -n infosecadventures.allsafe/.challenges.NoteReceiver #allsafe

we can use Medusa to sniff all exported intents and broadcast receivers

Firebase Realtime Database is a cloud-hosted NoSQL database provided by Google as part of the Firebase suite of mobile application development tools. It is designed to store and synchronize data in real-time between clients, making it particularly well-suited for building real-time and collaborative applications such as chat apps, online games, collaborative document editing, and more.

• test firebase data base, its found in Strings.xml ⇒ navigate to /.json
  
  

⇒ If accessed then its vulnerable and may allow Read/Write perms not only Read.

⇒ If permission denied then its all OK

• under <service> ⇒ check if Exported

• head to onStartCommand to understand the flow

adb shell am startservice com.htbridge.pivaa/.handlers.VulnerableService #PIVAA
adb shell am startservice infosecadventures.allsafe/.challenges.RecorderService

<provider> tag

NotesProvider Class:

• Content Provider URI schema ⇒ content://

• If the content provider is Exported we can directly call it

uri ⇒ is content:// then android:authorities

adb shell content query --uri "content://app.beetlebug.provider/users" #another example if theres a table u neeed to provide in the uri
adb shell content query --uri "content://infosecadventures.allsafe.dataprovider"

Row: 0 id=1, user=admin, note=I can not believe that Jill is still using 123456 as her passwor
Row: 1 id=2, user=elliot.alderson, note=A bug is never just a mistake. It represents
Row: 2 id=3, user=darlene.alderson, note=That’s the trick about money.
Row: 3 id=4, user=gideon.goddard, note=You’re never sure about anything unl

If its not exported

if it has ⇒ grantUriPermissions="true" then we can use this permission to access content://

by using another exported activity that can receive whole intent and redirerct it to this activity

⇒ In our example we found class of ProxyActivity, that takes intent as extra

and its exported in the manifest

<activity android:name="infosecadventures.allsafe.ProxyActivity" android:exported="true"/>

so our POC will be

• Known as "black-box" analysis, is the execution of the APK in a controlled environment (e.g., emulator or physical device). During execution, the tester monitors the app's behavior, network traffic, and interactions with the device's resources to identify vulnerabilities and security weaknesses.

• Dynamic analysis is usually conducted after the app has been deployed or during the testing phase. It assesses how the app behaves in a real-world scenario, including its interaction with external servers and services.

• Dynamic analysis focuses on runtime vulnerabilities, including improper data handling, sensitive data leakage, insecure communication, and runtime behavior anomalies.

• While dynamic analysis can involve automation for certain tasks (e.g., automated testing scripts), it often requires manual interaction to explore the app thoroughly.

• Common dynamic analysis tools for Android include mobile app penetration testing frameworks like Frida , Drozer, Burp Suite, and various mobile security testing platforms.

• logcat is a tool to monitor all logs from the device, to specify a pid we use --pid arg

we use it to check for any app leaks in logs during use

#In case of Diva ⇒ Dynamic allocation to the PID , now we can monitor Diva logs
adb logcat --pid=$(adb shell pidof -s jakhar.aseem.diva)

• logs are always inside Log.blabla e.g. Log.e for errors

as shown above the error is because of the Log.e part as it dumps the cc.txt as a string in the logs

Jadx can search in the entire App with keywords or Regex , so we can specify a Regex ⇒ ^Log.. to search for all types of logs , remove ^ if u didn’t find outputs

Mitigation : Don’t log sensitive info

• Also, its recommended checking for Hardcoded creds or crypto keys as well as checking in Strings.xml

• Check for Insecure Data storage, as it may be stored locally in shared_prefs directory in preferences.xml file

in ⇒ /data/data/YOUR_PACKAGE_NAME/shared_prefs/YOUR_PREFS_NAME.xml

Read mode about data storage here:

https://www.notion.so/02aae17ad648406bb91477d99704c0fc?pvs=25#8d1d1e1d14254e299a2836e74eeadee3

• If data is stored in a local database, we can examine it using sqlite3 and navigate through tables to dump creds

Version1

• A task is a collection of activities that users interact with when performing a certain job.

• The activities are arranged in a stack—the back stack)—in the order in which each activity is opened.

• The activity that is displayed on the screen is called a foreground activity and its task is called the foreground task. At a time, only one foreground task is visible on the screen.

Activities are stack structured, every activity u do in app is put on a stack, when u apply moveToBack it makes it go back down to the stack which makes it not the current active activity.

• excludeFromRecent: This attribute hides the app from both foreground and background while it's loaded and running in memory.

Task Affinity: Task affinity is an attribute defined in each <activity> tag in the AndroidManifest.xml file. It's a way of saying, "These activities belong together.”. By default, every activity has the same affinity as the package name.

• Developers can use this tag to group activities that work together. By default, activities in an app share the same task affinity.

• You can set task affinity using the following code:

  <activity android:taskAffinity="com.yourpackage.appname OR .task"/>

Launch Modes: Launch modes tell Android how to handle new instances of an activity.

There are several launch modes, including:

• The [launchMode] attribute specifies set of instructions for Android on how to open an activity.
  • Different activities in an app might need to be opened in different ways. This attribute helps developers tell Android the preferred way.

When the launchMode is set to singleTask, the Android system evaluates three possibilities and one of them is the reason why our attack is possible. Here they are -

• If the Activity instance already exists:
  Android resumes the existing instance instead of creating a new one. It means that there is at most one activity instance in the system under this mode.
  

• If creating a new activity instance is necessary:
  The Activity Manager Service (
  AMS) selects a task to host the newly created instance by finding a “matching” one in all existing tasks. An activity “matches” a task if they have the same task affinity. This is the reason why we can specify the same task affinity as the vulnerable app in our malware/attacker's app so it launches in their task instead of creating it's own.

• If no “matching” task found:
  The AMS creates a new task and makes the new activity instance the root activity of the newly created task.
  

Attack

• The victim needs to have the malicious app installed in his device.

• Then, he needs to open it before opening the vulnerable application.

• Then, when the vulnerable application is opened, the malicious application will be opened instead.

If this malicious application presents the same login as the vulnerable application the user won't have any means to know that he is putting his credentials in a malicious application.

You can find an attack implemented here: https://github.com/az0mb13/Task_Hijacking_Strandhogg

StrandHogg v2 :

StrandHogg 2.0 allows for broader attacks and is much more difficult to detect, making it, in effect, its predecessor’s ‘evil twin’. StrandHogg 2.0 doesn’t require a declaration in an Android manifest file, any special permissions, or root access.

• drozer agent and drozer in lab is used together as a C2 to make Enumeration, drozer don’t have any permissions except Internet perms. that means if it catch any data that means a vulnerability in the third party app not a permission given to drozer

• it can aslo enumerate all exported components in the APK then you have to go check manually, since the manifest file in real life is very large so it would be much easier to start with drozer
  Drozer cheat sheet

  

  listing information about installed packages on the Android device.

  dz> run app.package.list -f sieve // -f to filter or grep

  Provide some basic information about the package using the app.package.info command

  dz> run app.package.info -a com.mwr.example.sieve

  Identify the Attack Surface

  dz> run app.package.attacksurface com.mwr.example.sieve

  Launching Activities

  dz> run app.activity.info -a com.mwr.example.sieve
  
  Package: com.mwr.example.sieve
  com.mwr.example.sieve.FileSelectActivity
  com.mwr.example.sieve.MainLoginActivity
  com.mwr.example.sieve.PWList

  Launch exported Activities

  dz> run app.activity.start --component com.mwr.example.sieve com.mwr.example.sieve.PWList
  com.ifountain.opsgenie.ui.screens.deeplink.DeepLinkHandlerActivity

  Reading from Content Providers

  dz>run app.provider.info -a com.mwr.example.sieve

  Database-backed Content Providers (Data Leakage)

  Drozer provides a scanner module that brings together various ways to guess paths and divine a list of accessible content URIs:
  
  

  dz> run scanner.provider.finduris -a com.mwr.example.sieve
  
  Scanning com.mwr.example.sieve...
  Unable to Query content://com.mwr.example.sieve.DBContentProvider/ ...
  Unable to Query content://com.mwr.example.sieve.DBContentProvider/Keys
  Accessible content URIs:
  content://com.mwr.example.sieve.DBContentProvider/Keys/
  content://com.mwr.example.sieve.DBContentProvider/Passwords
  content://com.mwr.example.sieve.DBContentProvider/Passwords/

  We can now use other drozer modules to retrieve information from those content URIs, or even modify the data in the database:

  dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --vertical
  
  id: 1
  service: Email
  username: incognitoguy50
  password: PSFjqXIMVa5NJFudgDuuLVgJYFD+8w== (Base64-encoded) email: incognitoguy50@gmail.com

  Database-backed Content Providers (SQL Injection)

  dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "'"
  dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --selection "'"

  Android returns a very verbose error message, showing the entire query that it tried to execute.
  We can fully exploit this vulnerability to list all tables in the database:
  

  dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "* FROM SQLITE_MASTER WHERE type='table';--"
  dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "* FROM Key;--"

  File System-backed Content Providers

  dz> run app.provider.read content://com.mwr.example.sieve.FileBackupProvider/etc/hosts

  to dump the db to local machine

  dz> run app.provider.download content://com.mwr.example.sieve.FileBackupProvider/data /data/com.mwr.example.sieve/databases/database.db /home/user/database.db
  

  Content Provider Vulnerabilities

  dz> run scanner.provider.injection -a com.mwr.example.sieve
  Scanning com.mwr.example.sieve...
  Injection in Projection:
  content://com.mwr.example.sieve.DBContentProvider/Keys/
  content://com.mwr.example.sieve.DBContentProvider/Passwords
  content://com.mwr.example.sieve.DBContentProvider/Passwords/
  Injection in Selection:
  content://com.mwr.example.sieve.DBContentProvider/Keys/
  content://com.mwr.example.sieve.DBContentProvider/Passwords
  content://com.mwr.example.sieve.DBContentProvider/Passwords/

  to test LFI OR file path travesals Or reading local files via vulnerble content providers in the app

  dz> run scanner.provider.traversal -a com.mwr.example.sieve
  Scanning com.mwr.example.sieve...
  Vulnerable Providers:
  content://com.mwr.example.sieve.FileBackupProvider/
  content://com.mwr.example.sieve.FileBackupProvider

  to read

  dz> run app.provider.read content://com.mwr.example.sieve.FileBackupProvider/etc/hosts
  

  Interacting with Services

  dz> run app.service.info -a com.mwr.example.sieve
  

  Unintended Data Leakage

  $ pidcat com.mwr.example.sieve

  Attacking Services

  dz> run app.service.info --package org.owasp.goatdroid.fourgoats
  Package: org.owasp.goatdroid.fourgoats
    org.owasp.goatdroid.fourgoats.services.LocationService
      Permission: null

  Attacking Activities
  The components listed in the AndroidManifest.xml file
  

  dz>  org.owasp.goatdroid.fourgoats -u
  Package: org.owasp.goatdroid.fourgoats
    Exported Activities:
      org.owasp.goatdroid.fourgoats.activities.Main

  Activate the component

  dz> run app.activity.start --component org.owasp.goatdroid.fourgoats org.owasp.goatdroid.fourgoats.activities.ViewProfile
  

  Attacking Broadcast Receivers

  dz> run app.broadcast.info --package org.owasp.goatdroid.fourgoats
  Package: org.owasp.goatdroid.fourgoats
    org.owasp.goatdroid.fourgoats.broadcastreceivers.SendSMSNowReceiver
      Permission: null

  If you would see in the AndroidManifest.xml file of FourGoats application then you will find action name is org.owasp.goatdroid.fourgoats.SOCIAL_SMS and component name as org.owasp.goatdroid.fourgoats.broadcastreceivers.SendSMSNowReceiver . So we have to set these parameters in drozer accordingly.

  dz> run app.broadcast.send --action org.owasp.goatdroid.fourgoats.SOCIAL_SMS --component org.owasp.goatdroid.fourgoats.broadcastreceivers.SendSMSNowReceiver --extra string phoneNumber 1234 --extra string message "it's test"
  

  Start Drozer in Docker

  adb kill-server
  adb -a nodaemon server start

  adb connect 192.168.1.8:62001 # mobile ip

  adb forward tcp:31415 tcp:31415

  docker run -it fsecurelabs/drozer

  drozer console connect --server 192.168.1.5:31415 #IP kali

https://github.com/Ch0pin/medusa.git

reset
show all # to show all modules in Medusa

use [[MODULE NAME]] #e.g. use file_system/shared_preferences

run -f [[PACKAGE NAME]] #e.g. run -f infosecadventures.allsafe

the above example starts monitoring the APK if it stored anything in shared prefrences

Similar to Medusa, also based on Frida and communicate through Frida server.

objection -g  [[Package_Name]]  explore

# android [[Choose]]

Objection Memory Dump

…# memory search [[String]] --string to dump specefic strings

This hex value is displayed in the left to each string

Or you can dump all memory:

to bypass this function Boolean validition:

Java.perform(function(){ //34an function mwgoda

var rootCls = Java.use("sg.vantagepoint.a.c");

rootCls.a.implementation = function () {
console.log("Check A bypassed");
return false;}

rootCls.b.implementation = function () {
console.log("Check B bypassed");
return false;}

rootCls.c.implementation = function () {
console.log("Check C bypassed");
return false;}

});

root automation batching tools with Frida:

Frida CodeShare

"If I have seen further, it is by standing on the shoulders of giants."     -Sir Issac Newton

https://codeshare.frida.re/

and use ready payloads like:

Project: fridantiroot

 frida -U --codeshare dzonerzy/fridantiroot -f YOUR_BINARY

-U for USB connections

Magisk & Zyjisk in root and bypassing root detetction

Nowadays, there is something called systemless root , it makes the modifications at boot time in ROM and it didn’t modify in the file system like the old method. Magisk with Zygisk version is used to make systemless root

💡

There are two types of keys in android, its related to how android kernel signed while its compiling at the beginning

1. test keys → means its signed by android AOSP keys (Android Open Source Project), its public keys and known to anyone so the installed apps signed with this test keys. so this means that you can change or hijack system applications without detection. So finding a test keys may be an indication that this kernel has been hijacked.

2. release keys → its preferable that the kernel should sign with special release key with the access of the developer or manufacturer only

• Magisk

  Its System less root way. Its an easy way to install and uninstall root on devices. Its specially made to bypass safety net (its the official implementation from google in root detection).

  • Safety net

    SafetyNet is an Android API that provides a set of services and creates profiles of devices according to software and hardware information. This profile is then compared to a list of accepted device models that have passed Android compatibility testing. Google recommends using the feature as "an additional in-depth defense signal as part of an anti-abuse system".

    When you call this API, SafetyNet downloads a binary package containing the device validation code provided from Google, and the code is then dynamically executed via reflection. An analysis by John Kozyrakis showed that SafetyNet also attempts to detect whether the device is rooted, but exactly how that's determined is unclear.

    To use the API, an app may call the SafetyNetApi.attest method (which returns a JWS message with the Attestation Result) and then check the following fields:

    • ctsProfileMatch: If 'true', the device profile matches one of Google's listed devices.

    • basicIntegrity: If 'true', the device running the app likely hasn't been tampered with.

    • nonces: To match the response to its request.

    • timestampMs: To check how much time has passed since you made the request and you got the response. A delayed response may suggest suspicious activity.

    • apkPackageName, apkCertificateDigestSha256, apkDigestSha256: Provide information about the APK, which is used to verify the identity of the calling app. These parameters are absent if the API cannot reliably determine the APK information.

    https://github.com/OWASP/owasp-mastg/blob/master/Document/0x05j-Testing-Resiliency-Against-Reverse-Engineering.md

  💡

  Any application installed from google play store can call the safety net API and check for ctsProfile

  Recently, Magisk has a new version called Zygisk and this injects the Magisk app inside the zygot process (this process is responsible for spawning the applications in android) of the android directly. This makes the bypassing of root detection more efficient and stealthy.

  💡

  Magisk app has a feature called hide Magisk app and this allows you to make the appears as another one.

Magisk ⇒ safe Root batching and the ability of returning back is easy by just un installing it through the app

SaftyNet API is for google play installed app, check is the device is rooted

can be checked in play store settings

You should clear play store Cache before checking, if u r not certified , try to bypass root detection done by SaftyNet

after Android 10, Root detection is harder since its based now more on hardware

Zygisk : is what the Magisk developers call running Magisk in the Zygote Process of Android.

The Zygote Process is the first process that the OS starts when it boots up, similar to PID 1 on other Linux-based operating systems.

Since zygote starts first after system, it can hide root without sending data to apps.

Also it can bypass root detection to given Apps though Deny-List , you check app then restart

this would work for http , but in case of https

we will need to download the certificate of Burp in Android first

Change the certificate to cer rather than der

now install it from Android settings

Trust Manager and SSL Context Initialization:

In Android, the Trust Manager is responsible for managing certificates and deciding which certificates should be trusted when establishing secure connections using SSL/TLS. If a trust manager is compromised or not properly implemented, it can lead to security vulnerabilities.

Bypassing Trust Managers with Frida:

It can be used to intercept function calls, including those related to SSL/TLS connections. If an application is not using certificate pinning and relies solely on the default trust manager, a Frida script could potentially intercept and modify SSL/TLS traffic.

but Frida script won’t run on a Majisk or jygisk rooted device as they intercept traffic to bypass root detection:

this above won’t run in old Majisk ⇒ therefore to run Frida scripts while Majsik we use Frida on an already running process

script below, is used instead:

this script is a solution but it wont always go well from the first trial, You need to retry until u catch the right time before initialization of the Trust manager

as shown it failed in first trial, but succeeded in the 2nd

but the new ver5sion of Jyisk fixed this issue

just use then

frida -U -l hook.js -p [[PID]] 

frida --codeshare akabe1/frida-multiple-unpinning -U -f <appname>

In dealing with APKs, Burp would cause issues, since the APK dont see the Burp as a valid Certificate pinned to it form the server, and cause the connection not to be established correctly

this is due to SSL Pinning

This issue is due : when we install a Cert, its stored in User certificates not System Cert. and it’s not recommended to store it as System even if u r in a rooted device, as that would cause errors in Root Detection Bypasses

and as we see in the NSC.xml file ⇒ src of certs is only system

Solution here to Batch the APK:

1- check in AndroidManifist for the NSC file

2- apktool decompile

3- Reach the file and add user trust

4- Rebuild using APKtool

java -jar /bin/apktool.jar b indeed -o patched_indeed.apk #use this
apktool b APK-Dir/ -o APK_PATCHED.apk

5- Set certificates for the batched apk using

https://github.com/patrickfav/uber-apk-signer.git

finally adb install it and replace it with the real indeed apk

You Can bypass SSL Pinning using Frida Code Share , Medusa , Objection

Frida use the universal SSl pinning Code share

Medusa: use universal ssl pinning module

Objection:

CSRF or SSRF is the most popular web vulnerabilities, both depending on the same concept.

• Forgery a part of an authenticated request to perform an unwanted action or access sensitive data.

• In the mobile application, the same vulnerability class exists. There might be some differences from a web application, but it leads to the same thing. It came from the most common attack surface in a mobile application, which is deep links.

Deeplinks is now one of the important components of a mobile application. You always want to make it easy for your users to navigate your application components to view specific content. It easy! Implantation of deep links is easy! But parsing the received parameters from it is not easy.

Let us imagine that there is a deep link that helps the users to navigate to profile activity, its URI, e.g.: example://app/users?username=dphoeniixx

It’s simple, the application will try to match the deep link path to get target activity, or its configure then parse the inputs to pass it to the next stage. The above case will retrieve username parameter value from the deep link then pass it to the profile activity.

Profile Activity will send a request to the server to retrieve the user’s profile. Some APIs use parameters only for their inputs; some may use parameter and path segments. let’s imagine the following: https://api.example.com/v1/users/{username} is the endpoint that the application will send a request to it to retrieve the user’s profile

Here is the problem come, in this case, the attacker can forgery the request path using path traversal, e.g.: example://app/users?username=../../unwanted-endpoint%3fparam=value will request -> https://api.example.com/unwated-endpoint?param=value

Some deep links don’t parse their inputs from parameters, maybe path segments! e.g. : example://app/users/dphoeniixx. It’s still vulnerable; the attacker can encode the path traversal payload like that: example://app/users/..%2f..%2funwanted-endpoint%3fparam=value, don’t worry about the encoded input, Uri.getPathSegments Method will decode every path segment:

while ((current = path.indexOf('/', previous)) > -1) {
    // This check keeps us from adding a segment if the path starts
    // '/' and an empty segment for "//".
    if (previous < current) {
        String decodedSegment
                = decode(path.substring(previous, current));
        segmentBuilder.add(decodedSegment);
    }
    previous = current + 1;
}

Sometimes developers don’t use getPathSegments method to retrieve the URI’s path segments, but anyway, almost all web-server will decode the path and redirect to the canonicalized path, e.g.:

GET /v1/users/..%2f..%2funwated-endpoint%3fparam=value HTTP/1.1 -> HTTP/1.1 302..\nLocation: /unwanted-endpoint?param=value

The above example is difficult to exploit. It requires chaining with an open redirect or something. I will skip it now to start from easy exploits.

Some deep links lead to sending a forgery request path by POST, PUT or DELETE method. It is common on coupons, invites, promocodes, etc...

We can exploit it and forgery the request path to any endpoint that can do harmful things to the user, e.g.: example://app/promo?code=../users/me%3femail=attacker@gmail.com -> POST /v1/users/me?email=attacker@gmail.com (Account Takeover)

Please notice most of the time. You can put the POST body on the query string:

POST /change HTTP/1.1
....

password=123456

Same as

POST /change?password=123456 HTTP/1.1
....

1- check shared preferences (the code will show that he is storing inside it)

2- check databases if its encrypted or not

3- if there is createTempFile() , check for temp files.

4- if the app has storage permission access then he can access /sdcard

• Android pattern cracker tools :

  https://github.com/AleDiBen/APLBreaker

  https://github.com/sch3m4/androidpatternlock

  this tools are for applications but for the device pattern itself, you can use another tools.

  💡

  Device passwords will be stored at /data/system/gesture.key